在前兩天，我們理解了企業為什麼需要 RAG，以及它如何解決大型語言模型 (LLM) 的幻覺問題。今天，我們將深入探索 RAG 的核心架構，了解它是如何運作的。

想像一下，你是一位超市店員。一位顧客走過來問：「請問有賣濕紙巾嗎？」你並沒有盲目地猜測，而是憑藉你對超市商品位置的認知，迅速在腦海中搜尋相關資訊。你找到所有濕紙巾的品牌和它們所在的貨架位置，然後自信地回答：「我們有賣 A 牌和 B 牌的濕紙巾，它們都在第 X 排的架子上。」

這個例子對應到 RAG 的處理流程：

1. 使用者提出問題。

2. 系統會先把資料庫內容切分成許多小片段。這就像店員把整個超市的商品資料庫，拆解成「單一商品、位置、類型」等資訊。

3. 當使用者詢問「濕紙巾」時，系統就能快速找出相關片段（例如 A 牌與 B 牌的濕紙巾）。

4. 最後，再把這些片段和原始問題結合，生成清楚的回答。

RAG 系統的六大核心組件

就像店員需要一套清晰的流程來定位商品，RAG 也需要完整的架構來保證回答的準確性。
RAG 系統的效能與準確性取決於以下六個關鍵組件：

1. 數據攝取 (Ingestion)

來源：多樣化的資料來源，如 PDF 文件、企業內部資料庫、網頁內容或 API 數據。

前處理：這一步是關鍵。系統會對非結構化數據進行清洗，例如透過 OCR (光學字元辨識) 處理圖片文字、去除雜訊，並將所有資料統一格式，以便後續的處理和計算。

2. 文檔切分 (Chunking)

為什麼要切分？ 這是因為 LLM 的處理能力有字元 (token) 限制。將大型文檔切分成較小的、有意義的片段（chunks），不僅能解決這個問題，還能讓檢索更精確，減少不必要的資訊。

策略：常見的切分策略包括固定長度切分、根據語義關係切分，或是遞迴式切分，以確保每個片段都包含完整的語意單元。切分過大，檢索會不準確；切分過小，會丟失語意上下文，造成答案片段化。

3. 向量化 (Embedding)

原理：這一步是 RAG 的語義基礎。它使用嵌入模型 (embedding model) 將切分好的文字片段轉換成多維空間中的向量 (vector)，每個向量都代表了該片段的語意。語意相近的文字片段，它們的向量在空間中的距離也會比較近。

考量：選擇合適的嵌入模型至關重要，需考慮語言支援、精準度與運算成本。

4. 檢索 (Retrieval)

核心：這個過程就像是從圖書館中精準地找到需要的書。系統會將使用者的問題也轉換成向量，然後在向量資料庫 (vector database) 中，如 FAISS、Milvus 或 Pinecone，透過近似最近鄰 (ANN) 演算法（例如 HNSW），快速找到與問題向量最接近（即語意最相關）的文檔片段。

重要性：檢索的準確性直接決定了 LLM 最終能「看到哪些文件」，進而影響答案的品質。

5. 生成 (Generation)

流程：LLM 接收來自檢索階段的相關文檔片段，並將其與使用者的原始問題結合，作為上下文 (context)。

結果：LLM 根據這些豐富的上下文來產生最終答案，這些答案可以包含對來源的引用、摘要、以及符合特定格式的內容，大幅提升使用者體驗與答案的可信度。

6. 應用層 (Application Layer)

介面：這是使用者與 RAG 系統互動的門戶，可以是聊天機器人、知識庫查詢助手，或是整合到企業內部系統（如 Slack 或 CRM）的插件。

價值：將底層複雜的技術轉化為直觀、實用的解決方案，讓 RAG 的能力真正落地到各類業務場景中。

工程設計的思考

在將 RAG 應用於企業場景時，工程師會考量以下幾點：

模組化：為了靈活性和成本效益，系統的每個組件都應該是可替換的。例如，檢索庫是否能替換成效能更好的產品？或是在不同任務中，LLM 能否換成更便宜或更專業的模型？

效能瓶頸：確保整個系統的響應速度，特別是檢索和生成階段的延遲，這直接影響使用者體驗。

擴展性：系統是否能輕鬆支援多種語言、多個資料來源或大規模的資料增長？

維護性：知識庫的更新是個持續的過程。如何實現自動化的知識更新，而不是手動維護，是維持系統準確性的重要課題。例如，財報每季更新，若不能自動更新到向量資料庫，答案就會立刻過時。

考考你

1. 如果向量資料庫的規模從 1 萬筆增長到 1 億筆，你會如何確保檢索效率？
2. 在生成階段，應該強調「完整答案」還是「來源引用」？這兩者之間如何取捨？
3. 在多語言企業中（例如同時有中文、英文文件），你會選擇單一向量庫還是多個語言分開的庫？